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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314; "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server 
(http ://www. etsi.org/ipr) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by the Special Mobile Group (SMG). 

The present document describes the Subnetwork Dependent Convergence Protocol (SNDCP) for the General Packet 
Radio Service (GPRS) within the digital cellular telecommunications system. 

The contents of the present document may be subject to continuing work within SMG and may change following formal 
SMG approval. Should SMG modify the contents of the present document it will then be re-submitted for formal 
approval procedures by ETSI with an identifying change of release date and an increase in version number as follows: 

Version 6.x.y 

where: 

6 GSM Phase 2+ Release 1997; 

X the second digit is incremented for all changes of substance, i.e., technical enhancements, corrections, 
updates, etc.; 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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Scope 



The present document provides the description of the Subnetwork Dependent Convergence Protocol (SNDCP) for the 
General Packet Radio Service (GPRS). 

The user of the services provided by SNDCP is a packet data protocol (PDP) at the mobile Station (MS) or the Relay at 
the Serving GPRS Support Node (SGSN). Additionally, a control entity, e.g., AT command interpreter, may be an 
SNDCP user. SNDCP uses the services provided by the Logical Link Control (LLC) layer [4] and the Session 
Management (SM) sub-layer [2] . 

The main functions of SNDCP are: 

Multiplexing of several PDPs. 

Compression / decompression of user data. 

Compression / decompression of protocol control information. 

Segmentation of a network protocol data unit (N-PDU) into Logical Link Control Protocol Data Units 
(LL-PDUs) and re-assembly of LL-PDUs into an N-PDU. 

GSM 04.65 is applicable to GPRS MS and SGSN. 
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• For this Release 1997 document, references to GSM documents are for Release 1997 versions (version 6.x.y). 
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[6] GSM 04.64: "Digital cellular telecommunication system (Phase 2+); General Packet Radio Service 

(GPRS); Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link Control (LLC) 
Layer Specification" . 

[7] GSM 09.60: "Digital cellular telecommunications system (Phase 2+), General Packet Radio 

Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface". 
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[8] ITU-T, Recommendation V.42 bis: "Data compression procedures for data circuit- terminating 

equipment (DCE) using error correcting procedures". 

[9] RFC-1 144, V. Jacobson: "Compressing TCP/IP Headers for Low-Speed Serial Links". 



3 Definitions and abbreviations 

3.1 Definitions 

In addition to abbreviations in 01.04 [1] and 02.60 [2] the following abbreviations apply: 

N201 LLC layer parameter (see GSM 04.64 for clarity). Defines maximum number of octets in 

the information field of LL-PDU. Separate values are applicable for I (see N201-I), U and 
UI (see N201-U) LL-PDUs. 

N201-I LLC layer parameter (see GSM 04.64 for clarity). Defines maximum number of octets 

available to a SN-DATA PDU for a specific SAPI. 

N201-U LLC layer parameter (see GSM 04.64 for clarity). Defines maximum number of octets 

available to a SN-UNITDATA PDU for a specific SAPI. 

N-PDU number A sequence number assigned to N-PDUs per NSAPI. 

NSAPI For each SN-PDU the NSAPI is an index to the PDP context of the PDP that is using the 

services provided by the SNDCP layer. 

Receive N-PDU number The value of the N-PDU number expected in the next N-PDU received by an NSAPI 

using acknowledged peer-to-peer LLC operation. 

Recovery state A state for an NSAPI in which duplicated received N-PDUs shall be detected and 

discarded. The recovery state only applies to NSAPIs using acknowledged peer-to-peer 
LLC operation. 

SAPI SAPI identifies the Service Access Point that the SN-PDU is using at the LLC layer. 

Segment number A sequence number assigned to SN-UNITDATA PDUs carrying segments of an N-PDU. 

Send N-PDU number The value to be assigned as the N-PDU number to the next N-PDU received from the 

SNDCP user by an NSAPI using acknowledged peer-to-peer LLC operation. 

Send N-PDU number (unacknowledged) The value to be assigned as the N-PDU number to the next N-PDU 

received from the SNDCP user by an NSAPI using unacknowledged peer-to-peer LLC 
operation. 

SNDCP entity The SNDCP entity handles the service functions provided by the SNDCP layer. The 

SNDCP entity is temporary logical link identity specific. 

SNDCP management entity The SNDCP management entity handles communication with SM sub-layer and controls 

the operation of the SNDCP entity. 

SNDCP user Protocol entity that is using the services provided by the SNDCP layer. PDP entities and 

control entities, e.g., AT command interpreter, are the SNDCP users at the MS. Relay 
entity is the SNDCP user at the SGSN. 

SNDCP XID block The collection of SNDCP XID parameters being negotiated. It is transferred by the 

LL-XID and LL-ESTABLISH primitives between SNDCP and LLC. 

Refer to GSM 02.60 [2] for further GPRS definitions. 



£75/ 



(GSM 04.65 version 6.5.1 Release 1997) 



ETSI TS 101 297 V6.5.1 (1999-11) 



3.2 



Abbreviations 



In addition to abbreviations in GSM 01.04 [1], GSM 02.60 [2], and GSM 03.60 [3], the following abbreviations apply: 

DCOMP Identifier of the user data compression algorithm used for the N-PDU 

F First segment indicator bit 

GMM GPRS Mobility Management 

IP Internet Protocol 

LLC Logical Link Control 

M More bit used to indicate the last segment of N-PDU 

N-PDU Network Protocol Data Unit 

NS API Network Layer Service Access Point Identifier 

P Propose bit 

PCOMP Identifier of the protocol control information compression algorithm used for the N-PDU 

PDP Packet Data Protocol e.g., IP or X.25 

PDU Protocol Data Unit 

PTP Point to Point 

QoS Quality of Service 

SAPI Service Access Point Identifier 

SDU Service Data Unit 

SGSN Serving GPRS Support Node 

SM Session Management 

SNDCP Subnetwork Dependent Convergence Protocol 

SNSM SNDCP-SM 

TCP Transmission Control Protocol 

TLLI Temporary Logical Link Identifier 

X Spare bit 



General 



The present document describes the functionality of the GPRS SNDCP. The overall GPRS logical architecture is 
defined in GSM 03.60 [3]. Location of the SNDCP in GPRS protocol stack can be seen in Figure 1. 
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Figure 1 : GPRS protocol stack 

Network layer protocols are intended to be capable of operating over services derived from a wide variety of 
subnetworks and data links. GPRS supports several network layer protocols providing protocol transparency for the 
users of the service. Introduction of new network layer protocols to be transferred over GPRS shall be possible without 
any changes to GPRS. Therefore, all functions related to transfer of Network layer Protocol Data Units (N-PDUs) shall 
be carried out in a transparent way by the GPRS network entities. This is one of the requirements for GPRS SNDCP. 

Another requirement for the SNDCP is to provide functions that help to improve channel efficiency. This requirement is 
fulfilled by means of compression techniques. 
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The set of protocol entities above SNDCP consists of commonly used network protocols. They all use the same SNDCP 
entity, which then performs multiplexing of data coming from different sources to be sent using the service provided by 
the LLC layer (Figure 2). The Network Service Access Point Identifier (NSAPI) is an index to the PDP context (see 
GSM 03.60 [3]) of the PDP that is using the services provided by SNDCP. One PDP may have several PDP contexts 
and NSAPIs. However, it is possible that each allocated NSAPI is used by separate PDP. Each active NSAPI shall use 
the services provided by the Service Access Point Identifier (S API) in the LLC layer. Several NSAPIs may be 
associated with the same SAPI. 

Since the adaptation of different network layer protocols to SNDCP is implementation dependent, it is not defined in the 
present document. 




N-PDU 



SN-PDU 



LLC 



Figure 2: Example for multiplexing of different protocols 



5 Service primitives and functions 

5.1 Service primitives 

This subclause explains the service primitives used for communication between the SNDCP layer and other layers. See 
also GSM 04.07 [4] to get an overall picture of the service primitives. Figure 3 illustrates the service access points 
through which the primitives are carried out. 
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Figure 3: Service Access Points provided and used by SNDCP 

5.1 .1 SNDCP service primitives 

The primitives provided by the SNDCP layer are listed in Table 1 . 

Table 1 : SNDCP layer service primitives 



Generic Name 


Type 


Parameters 


Request 


Indication Response 


Confirm 


SNDCP User (PDP or the SGSN Relay) <^ SNDCP | 


SN-DATA 


X 


- 


- 


- 


N-PDU, NSAPI, N-PDU 
Number 


SN-DATA 


- 


X 


- 


- 


N-PDU, NSAPI 


SN-UNITDATA 


X 


X 


- 


- 


N-PDU, NSAPI 


SN-XID 


X 


X 


- 


- 


Requested SNDCP XID 
Parameters 


SN-XID 


- 


- 


X 


X 


Negotiated SNDCP XID 
Parameters 



5.1.1.1 



SN-DATA.request 



Request used by the SNDCP user for acknowledged transmission of N-PDU. The successful transmission of SN-PDU 
shall be confirmed by the LLC layer. The SN-DATA.request primitive conveys NSAPI to identify the PDP using the 
service. N-PDU Number, if present, indicates the N-PDU number previously assigned to this N-PDU. 

NOTE: An N-PDU number may have been assigned to an N-PDU by the old SGSN before an inter-SGSN 
routeing area update. 
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5.1.1.2 SN-DATA.indication 

Indication used by the SNDCP entity to deliver the received N-PDU to the SNDCP user. Successful reception has been 
acknowledged by the LLC layer. 

5.1.1.3 SN-UNITDATA.request 

Request used by the SNDCP user for unacknowledged transmission of N-PDU. The SN-UNITDATA.request primitive 
conveys NSAPI to identify the PDP using the service. 

5.1.1.4 SN-UNITDATA.indication 

Indication used by the SNDCP entity to deliver the received N-PDU to the SNDCP user. 

5.1.1.5 SN-XID.request 

Request used by the SNDCP user at the initiating entity to deliver the list of requested XID parameters to the peer entity. 

5.1.1.6 SN-XID. indication 

Indication used by the SNDCP entity to deliver the list of requested XID parameters to the SNDCP user. 

5.1.1.7 SN-XID. response 

Response used by the SNDCP user to deliver the list of negotiated XID parameters to the peer entity. 

5.1.1.8 SN-XID.confirm 

Confirm used by the SNDCP entity to deliver the list of negotiated XID parameters to the SNDCP user. 

5.1 .2 Service primitives used by SNDCP layer 

The SNDCP layer uses the service primitives provided by the SM sublayer and the LLC layer (see Table 2). SM is 
specified in GSM 04.08 [5] and LLC in GSM 04.64 [6]. 
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Table 2: Service primitives used by the SNDCP entity 



Generic Name 


Type 


Parameters 


Request 


Indication Response 


Confirm 


SNDCP <^ LLC 


LL-RESET 


- 


X 


- 


- 


TLLI 


LL-ESTABLISH 


X 


- 


- 


- 


TLLI, XID Requested 


LL-ESTABLISH 


- 


X 


- 


- 


TLLI, XID Requested, 
N201-I, N201-U 


LL-ESTABLISH 


- 


- 


X 


- 


TLLI, XID Negotiated 


LL-ESTABLISH 


- 


- 


- 


X 


TLLI, XID Negotiated, 
N201-I, N201-U 


LL-RELEASE 


X 


- 


- 


- 


TLLI, Local 


LL-RELEASE 


- 


X 


- 


- 


TLLI, Cause 


LL-RELEASE 






- 


X 


TLLI 


LL-XID 


X 


- 


- 


- 


TLLI, XID Requested 


LL-XID 


- 


X 


- 


- 


TLLI, XID Requested, 
N201-I, N201-U 


LL-XID 


- 


- 


X 


- 


TLLI, XID Negotiated 


LL-XID 


- 


- 


- 


X 


TLLI, XID Negotiated, 
N201-I, N201-U 


LL-DATA 


X 








TLLI, SN-PDU, Reference, 
QoS Parameters, Radio 
Priority 


LL-DATA 


- 


X 


- 


- 


TLLI, SN-PDU 


LL-DATA 


- 


- 


- 


X 


TLLI, Reference 


LL-UNITDATA 


X 








TLLI, SN-PDU, QoS 
Parameters, Radio Priority, 
Cipher 


LL-UNITDATA 


- 


X 


- 


- 


TLLI, SN-PDU 


LL-STATUS 


- 


X 


- 


- 


TLLI, Cause 


SNDCP <^ SM 


SNSM-ACTIVATE 




X 


- 


- 


TLLI, NSAPI, QoS profile, 
SAPI, Radio Priority 


SNSM-ACTIVATE 


- 


- 


X 




TLLI, NSAPI 


SNSM-DEACTIVATE 


- 


X 


- 


- 


TLLI, NSAPI(s), LLC 
Release Indicator 


SNSM-DEACTIVATE 


- 


- 


X 


- 


TLLI, NSAPI 


SNSM-MODIFY 




X 






TLLI, NSAPI, QoS Profile, 
SAPI, Radio Priority, Send 
N-PDU Number, Receive 
N-PDU Number 


SNSM-MODIFY 


- 


- 


X 


- 


TLLI, NSAPI 


SNSM-STATUS 


X 


- 


- 


- 


TLLI, SAPI, Cause 


SNSM-SEQUENCE 


- 


X 


X 


- 


TLLI, NSAPI, Receive 
N-PDU Number 


SNSM-STOP-ASSIGN 


- 


X 


- 


- 


TLLI, NSAPI 



5.1.2.1 



LL-RESET.indication 



Indication used by the LLC layer in the SGSN to indicate to the SNDCP layer that the Reset XID parameter has been 
transmitted, and by the LLC layer in the MS to indicate to the SNDCP layer that the Reset XID parameter has been 
received. 

Upon receipt of the LL-RESET.indication, the SNDCP layer shall: 

treat all outstanding SNDCP <-^ LLC request type primitives as not sent; 

reset all SNDCP XID parameters to their default values; 

in the MS, for every NSAPI using unacknowledged peer-to-peer LLC operation, set the Send N-PDU number 
(unacknowledged) to 0; and 
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for every NSAPI using acknowledged peer-to-peer LLC operation, enter the recovery state and suspend the 
transmission of SN-PDUs until an SNSM-SEQUENCE.indication primitive is received for the NSAPI. 

5.1.2.2 LL-ESTABLISH.request 

Request used by the SNDCP layer to establish or re-establish acknowledged peer-to-peer operation for a SAPI in the 
LLC layer. XID Requested is used to deliver the requested SNDCP XID parameters to the LLC layer. 

5.1.2.3 LL-ESTABLISH. indication 

Indication used by the LLC layer to inform the SNDCP layer about establishment or re-establishment of acknowledged 
peer-to-peer operation for a SAPI in the LLC layer. XID Requested is used to deliver the requested SNDCP XID 
parameters to the SNDCP layer. In case of a re-establishment, all NS APIs mapped to the affected SAPI shall enter the 
recovery state, and all buffered N-PDUs (i.e., the ones whose complete reception has not been acknowledged and the 
ones that have not been transmitted yet) shall be transmitted starting with the oldest N-PDU when the link is re- 
established. Also all compression entities using acknowledged peer-to-peer LLC operation on this SAPI are reset. 

5.1.2.4 LL-ESTABLISH. response 

Response used by the SNDCP layer after reception of the LL-ESTABLISH. indication. XID Negotiated is used to 
deliver the negotiated SNDCP XID parameters to the LLC layer. 

5.1.2.5 LL-ESTABLISH.confirm 

Confirmation used by the LLC layer to inform the SNDCP layer about successful initiation of acknowledged peer-to- 
peer operation for a SAPI in the LLC layer. XID Negotiated is used to deliver the negotiated SNDCP XID parameters to 
the SNDCP layer. In case of a re-establishment, all NSAPIs mapped to the affected SAPI shall enter the recovery state, 
and all buffered N-PDUs (i.e., the ones whose complete reception has not been acknowledged and the ones that have not 
been transmitted yet) shall be transmitted starting with the oldest N-PDU when the link is re-established. Also all 
compression entities using acknowledged peer-to-peer LLC operation on this SAPI are reset. 

5.1.2.6 LL-RELEASE.request 

Request used by the SNDCP layer to release acknowledged peer-to-peer operation for a SAPI in the LLC layer. The 
Local parameter indicates whether the termination shall be local (see 04.64 for details). 

5.1.2.7 LL-RELEASE.indication 

Indication used by the LLC layer to inform the SNDCP layer about termination of acknowledged peer-to-peer operation 
for a SAPI in the LLC layer. The Cause parameter indicates the cause for the termination. 

On receipt of LL-RELEASE.indication, compressed N-PDUs queuing to be forwarded to the affected SAPI are deleted 
from the SNDCP layer. Also all compression entities using acknowledged peer-to-peer LLC operation on this SAPI are 
reset. 

5.1.2.8 LL-RELEASE.confirm 

Confirmation used by the LLC layer to inform the SNDCP layer about termination of acknowledged peer-to-peer 
operation for a SAPI in the LLC layer. On receipt of LL-RELEASE.confirm, compressed N-PDUs queuing to be 
forwarded to the affected SAPI are deleted from the SNDCP layer. Also all compression entities using acknowledged 
peer-to-peer LLC operation on this SAPI are reset. 

5.1.2.9 LL-XID. request 

Request used by the SNDCP layer to deliver the requested SNDCP XID parameters to the LLC layer. 

5.1.2.10 LL-XID. indication 

Indication used by the LLC layer to deliver the requested SNDCP XID parameters to the SNDCP layer. 
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5.1.2.11 LL-XID. response 

Response used by the SNDCP layer to deliver the negotiated SNDCP XID parameters to the LLC layer. 

5.1.2.12 LL-XID.confirm 

Confirm used by the LLC layer to deliver the negotiated SNDCP XID parameters to the SNDCP layer. 

5.1.2.13 LL-DATA.request 

Request used by the SNDCP layer for acknowledged transmission of an SN-PDU. The SNDCP entity shall associate a 
reference parameter for each LL-DATA.request. QoS Parameters in the SGSN includes precedence class, delay class, 
and peak throughput. QoS Parameters in the MS includes peak throughput. QoS Parameters is defined as part of the 
Quality of Service information element in GSM 04.08. Radio Priority is included only in the MS, and indicates the radio 
priority level to be used by RLC/MAC. 

Acknowledged peer-to-peer LLC operation for the SAPI used shall be established using the LL-ESTABLISH primitives, 
before the LL-DATA.request may be used. 

5.1.2.14 LL-DATA.indication 

Indication used by the LLC layer to deliver the successfully received SN-PDU to the SNDCP layer. 

5.1.2.15 LL-DATA.confirm 

Confirm used by the LLC layer to inform SNDCP layer about successful transmission of SN-PDU. The primitive 
includes a reference parameter from which the SNDCP entity shall identify the LL-DATA.request this confirmation was 
associated with. All buffered N-PDUs whose complete reception is confirmed are deleted. 

5.1.2.16 LL-UNITDATA.request 

Request used by the SNDCP layer for unacknowledged transmission of a SN-PDU. Unconfirmed transmission shall be 
used by the LLC layer. 

Acknowledged peer-to-peer LLC operation does not need to be established before unacknowledged transmission is 
allowed. 

QoS Parameters in the SGSN includes precedence class, delay class, reliability class, and peak throughput. QoS 
Parameters in the MS includes peak throughput and reliability class. Reliability class indicates whether the LLC frame 
carrying the SN-PDU shall be transmitted in protected or unprotected mode, and whether RLC/MAC acknowledged or 
unacknowledged mode shall be used. Radio Priority is included only in the MS, and indicates the radio priority level to 
be used by RLC/MAC. 

5.1.2.17 LL-UNITDATA.indication 

Indication used by the LLC layer to deliver the received SN-PDU to the SNDCP layer. There is no need for 
acknowledged peer-to-peer LLC operation for unacknowledged transmission of SN-PDU. 

5.1.2.18 LL-STATUS.indication 

Indication used by the LLC layer to inform SNDCP when an LLC error that cannot be corrected by the LLC layer has 
occurred. The Cause parameter indicates the cause of the failure. 

On receipt of LL-STATUS.indication, SNDCP shall inform the SM sub-layer by means of the SNSM-STATUS .request 
primitive. 
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5.1 .2.1 9 SNSM-ACTIVATE.indication 

Indication used by the SM entity to inform the SNDCP entity that an NSAPI has been activated for data transfer. It also 
informs the SNDCP entity about the negotiated QoS profile (see GSM 04.08), the SAPI assigned for this NSAPI, and, in 
the MS, the radio priority level to be used by RLC/MAC. 

If the NSAPI activated uses the acknowledged peer-to-peer LLC operation, the NSAPI shall enter the recovery state. 

Upon reception of the SNSM-ACTIVATE.indication from the SM sublayer, the SNDCP entity shall, if necessary, 
establish the acknowledged peer-to-peer LLC operation for the indicated SAPI. The establishment criteria and 
procedure are described in subclause 6.2.1. 

5.1.2.20 SNSM-ACTIVATE. response 

Response used by the SNDCP layer to inform SM entity that the indicated NSAPI is now in use and that the 
acknowledged peer-to-peer LLC operation for the indicated SAPI is established, if necessary. 

5.1 .2.21 SNSM-DEACTIVATE.indication 

Indication used by the SM entity to inform the SNDCP entity that an NSAPI has been deallocated and cannot be used by 
the SNDCP entity anymore. All buffered N-PDUs corresponding to this NSAPI are deleted. 

Upon reception of the SNSM-DEACTIVATE.indication, the SNDCP entity shall, if necessary, release the 
acknowledged peer-to-peer LLC operation for the associated SAPI. The release criteria and procedure are described in 
subclause 6.2.2. 

5.1 .2.22 SNSM-DEACTIVATE.response 

Response used by the SNDCP layer to inform SM entity that the NSAPI indicated is no longer in use and that the 
acknowledged peer-to-peer LLC operation for the associated SAPI is released, if necessary. 

5.1.2.23 SNSM-MODIFY.indication 

Indication used by the SM entity to trigger change of the QoS profile (see GSM 04.08) for an NSAPI and indication of 
the SAPI to be used. It is also used by the SM entity in the SGSN to inform the SNDCP entity that an NSAPI shall be 
created, together with the (re-)negotiated QoS profile, the SAPI assigned, and, in the MS, the radio priority level to be 
used by RLC/MAC. 

NOTE: The latter is performed in the new SGSN during an Inter-SGSN Routeing Area Update. 

Upon reception of the SNSM-MODIFY.indication from the SM sublayer: 

the SNDCP entity shall, if necessary, establish the acknowledged peer-to-peer LLC operation for the indicated 
SAPI (the establishment criteria and procedure are described in subclause 6.2.1); and 

the SNDCP entity shall also, if necessary, release the acknowledged peer-to-peer LLC operation for the 
originally-assigned SAPI (the release criteria and procedure are described in subclause 6.2.2). 

If the SNSM-MODIFY.indication applies to an existing NSAPI, and: 

if the peer-to-peer LLC operation mode is changed from acknowledged to unacknowledged, then all buffered 
N-PDUs shall be deleted, and the Send N-PDU number (unacknowledged) shall be set to 0; and 

if the peer-to-peer LLC operation mode is changed from unacknowledged to acknowledged, then the Send 
N-PDU number and Receive N-PDU number shall be set to 0. 

In addition, if the newly-assigned SAPI is different from the original SAPI: 

- LL-D AT A. indication, LL-DATA.confirm and LL-UNITDATA.indication received on the old SAPI shall be 
ignored; 

- LL-DATA.request and LL-UNITDATA.request shall be sent on the new SAPI; and 
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if acknowledged peer-to-peer LLC operation is used both before and after the receipt of the SNSM- 
MODIFY.indication, then the NSAPI shall enter the recovery state, and all buffered N-PDUs (i.e., the ones 
whose complete reception has not been acknowledged and the ones that have not been transmitted yet) shall be 
transmitted starting from the oldest N-PDU. 

If the SNSM-MODIFY.indication signifies the creation of an NSAPI (i.e., the specified NSAPI does not exist), and: 

if unacknowledged peer-to-peer LLC operation is specified in the QoS profile, then the Send N-PDU number 
(unacknowledged) shall be set to 0; and 

if acknowledged peer-to-peer LLC operation is specified in the QoS profile, then the Send N-PDU number and 
the Receive N-PDU number variables shall be set to the values stated in the primitive. 

5.1.2.24 SNSM-MODIFY.response 

Response used by the SNDCP entity to inform the SM entity that the indicated NSAPI and QoS profile are now in use 
and the acknowledged peer-to-peer LLC operations for the appropriate SAPIs are established and/or released, if 
necessary. 

5.1.2.25 SNSM-STATUS.request 

This primitive is used by the SNDCP layer to inform the SM sub-layer that SNDCP cannot continue its operation due to 
errors at the LLC layer (as indicated with LL-RELEASE.indication) or at the SNDCP layer. The Cause parameter 
indicates the cause of the error. 

5.1 .2.26 SNSM-SEQUENCE. indication 

This primitive is used during an inter-SGSN routeing area update and applies only to NSAPIs using acknowledged peer- 
to-peer LLC operation. When the primitive is used in the MS, the Receive N-PDU number parameter indicates the 
Receive N-PDU number in the SGSN. When the primitive is used in the SGSN, the Receive N-PDU number parameter 
indicates the Receive N-PDU number in the MS. If a buffered N-PDU is confirmed by the Receive N-PDU number 
parameter to have been received by the peer SNDCP entity, the N-PDU shall be deleted from the buffer. In addition, the 
receipt of this primitive by the SNDCP entity resumes the transmission of SN-PDUs for the NSAPI, and all buffered 
N-PDUs (i.e., the ones whose complete reception has not been acknowledged and the ones that have not been 
transmitted yet) shall be transmitted starting from the oldest N-PDU. If acknowledged peer-to-peer LLC operation has 
not yet been established for the S API used by this NSAPI, the transmission of the buffered N-PDUs shall begin only 
after the receipt of the LL-ESTABLISH. indication or LL-ESTABLISH. confirm primitive. 

5.1.2.27 SNSM-SEQUENCE.response 

This primitive is used during an inter-SGSN routeing area update and applies only to NSAPIs using acknowledged peer- 
to-peer LLC operation. The primitive is used by the SNDCP layer in the MS following receipt of an SNSM- 
SEQUENCE.indcation, in order to return the Receive N-PDU number to the SGSN during an ongoing inter-SGSN 
routeing area update. 

5.1 .2.28 SNSM-STOP-ASSIGN. indication 

This primitive is used during an inter-SGSN routeing area update in the old SGSN by the SM entity to inform the 
SNDCP entity to stop assigning N-PDU numbers to N-PDUs received through the SN-DATA.request primitive. The 
primitive is sent before the Send N-PDU number and the Receive N-PDU number are transferred to the new SGSN. 

5.2 Service functions 

SNDCP shall perform the following functions (see Figure 3): 

Mapping of SN-DATA primitives onto LL-DATA primitives. 
- Mapping of SN-UNITDATA primitives onto LL-UNITDATA primitives. 

Multiplexing of N-PDUs from one or several network layer entities onto the appropriate LLC connection. 
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Establishment, re-establishment and release of acknowledged peer-to-peer LLC operation. 

Supplementing the LLC layer in maintaining data integrity for acknowledged peer-to-peer LLC operation by 
buffering and retransmission of N-PDUs. 

Management of delivery sequence for each NS API, independently. 

Compression of redundant protocol control information (e.g., TCP/IP header) at the transmitting entity and 
decompression at the receiving entity. The compression method is specific to the particular network layer or 
transport layer protocols in use. 

Compression of redundant user data at the transmitting entity and decompression at the receiving entity. Data 
compression is performed independently for each SAPI, and may be performed independently for each PDP 
context. Compression parameters are negotiated between the MS and the SGSN. 

Segmentation and reassembly. The output of the compressor functions is segmented to the maximum length of 
LL-PDU. These procedures are independent of the particular network layer protocol in use. 

Negotiation of the XID parameters between peer SNDCP entities using XID exchange. 

Figure 4 shows the transmission flow through SNDCP layer. The order of functions is the following: 

Protocol control information compression. 

User data compression. 

- Segmentation of compressed information into SN-DATA or SN-UNITDATA PDUs. 
The order of functions is vice versa in the reception flow: 

- Reassembly of SN-PDUs to N-PDUs. 
User data decompression. 

Protocol control information decompression. 
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Figure 4: SNDCP model 

The SNDCP layer expects the following services to be provided by the LLC layer. LLC layer fanctionaUty is defined in 
GSM 04.64 [6]: 

Acknowledged and unacknowledged data transfer. 

Point-to-point and point-to-multipoint data transfer. 

In-order delivery of SN-PDUs per SAPI (i.e., SN-PDUs using the same S API shall appear at the receiving end in 
the same order as transmitted). This is required only for acknowledged service. 

- QoS profile-based transfer of SN-PDUs. 
Support for variable length SN-PDUs. 

- Transfer of SNDCP XID parameters. 
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The SNDCP layer expects the following services to be provided by the SM sublayer. SM sublayer functionality is 
defined in GSM 04.08 [5]: 

Activation and deactivation of PDP Contexts and informing the SNDCP layer when change in PDP context has 
happened. 

- Carrying out Inter SGSN Routing Area Update and informing the SNDCP layer in the SGSN when the N-PDUs 
shall be tunnelled to the new SGSN. 

Notifying the SNDCP layer when there is need to change the QoS profile parameters of the PDP contexts. 



6 Protocol functions 

6.1 Multiplexing of N-PDUs 

The NS API field shall be used for the identification of the specific PDP type and PDP address pair that is using the 
services provided by the SNDCP layer. The MS allocates NSAPIs dynamically at the PDP Context Activation. The 
NSAPI is delivered by the SM sub-layer to the SNDCP layer with the SNSM-ACTIVATE.indication primitive. The 
transmitting SNDCP entity shall insert the NSAPI value for each N-PDU. The peer SNDCP entity uses the NSAPI to 
identify the SNDCP user the N-PDU is targeted. Table 3 shows an example for the allocation of the NSAPIs. 

Table 3: Example of the NSAPI allocation 



PDP type 


Allocated NSAPI 


PDP address 


IP 


12 


133.12.75.111 


X.25 


13 


13254 



6.2 Establishment and release of acknowledged peer-to-peer 
LLC operation 

The SNDCP layer shall be responsible for establishing, re-establishing and releasing the acknowledged peer-to-peer 
LLC operation. 

Re-establishment and release of the acknowledged peer-to-peer LLC operation may also be initiated by the LLC layer. 
The conditions under which this may happen are described in GSM 04.64. 

Negotiation of SNDCP XID parameters may be carried out in conjunction with the establishment or re-establishment 
procedure. It is also possible to negotiate SNDCP XID parameters independently from the establishment or re- 
establishment procedure, by using the LL-XID primitives. 

6.2.1 Establishment of acknowledged peer-to-peer LLC operation 
6.2.1 .1 Establishment criteria 

If acknowledged peer-to-peer LLC operation is required by an NSAPI (as indicated by the QoS profile) but is not yet 
established for the SAPI used by the NSAPI, then the SNDCP layer shall initiate the establishment procedure. 

The SNDCP layer at the MS shall initiate the establishment, using the procedure in subclause 6.2. L3, upon receipt of 
the SNSM-ACTIVATE.indication primitive. 

The SNDCP layer at the SGSN shall initiate the establishment upon receipt of the SNSM-MODIFY. indication primitive. 
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6.2.1.2 



Re-establishment of the acknowledged peer-to-peer LLC operation 



The SNDCP layer may initiate re-establishment of the acknowledged peer-to-peer LLC operation for a S API under 
certain situations, for example when an error is detected by a V.42 bis data compression entity used for acknowledged 
data transfer. 

The LLC layer may also initiate re-establishment of the acknowledged peer-to-peer LLC operation for a S API under 
situations described in GSM 04.64. The LLC layer informs the SNDCP layers of link re-establishment using the 
LL-ESTABLISH.indication primitive. This is shown in Figure 5. 
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Figures: LLC-initiated re-establishment 



6.2.1.3 



Establishment procedure 



The SNDCP layer shall initiate the establishment or re-establishment by sending an LL-ESTABLISH.request primitive 
to the relevant LLC SAP. SNDCP XID parameters may be included in an SNDCP XID block in the 
LL-ESTABLISH.request primitive. If no SNDCP XID parameter is to be included, an empty SNDCP XID block shall 
be included. 

Following the sending of the LL-ESTABLISH.request primitive, the SNDCP layer shall suspend the transfer of 
SN-DATA and SN-UNITDATA primitives to the LLC SAP to which the LL-ESTABLISH.request is sent. Transfer of 
SN-DATA and SN-UNITDATA primitives shall resume when the establishment procedure ends through one of the 
following means: 

successful (receiving LL-ESTABLISH. confirm); 

failure (receiving LL-RELEASE.indication); or 

successful following collision resolution (receiving LL-ESTABLISH.indication and sending 
LL-ESTABLISH.response, see subclause 6.2.1.4). 

Upon receipt of an LL-ESTABLISH.indication primitive, if an SNDCP XID block is present, the peer SNDCP entity 
shall respond with an LL-ESTABLISH.response primitive. SNDCP XID parameters may be included in an SNDCP XID 
block in the LL-ESTABLISH.response primitive. If no SNDCP XID parameter is to be included, an empty SNDCP XID 
block shall be included. If there is no SNDCP XID block in the LL-ESTABLISH.indication primitive, the peer SNDCP 
entity shall not respond with an LL-ESTABLISH.response primitive. 
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Figure 6: SNDCP-initiated establishment / re-establishment 



6.2.1.4 



Exceptional situations 



If the originator of the establishment procedure receives an LL-RELEASE.indication with Cause "DM received", it shall 
inform the SM sub-layer using the SNSM-STATUS .request primitive with Cause "DM received". SM shall then 
deactivate all PDP contexts for that SAPI requiring acknowledged peer-to-peer LLC operation. 

If the originator of the establishment procedure receives an LL-RELEASE.indication with Cause "invalid XID response" 
or an LL-STATUS. indication with Cause "invalid XID response", then it shall inform the SM sub-layer using the 
SNSM-STATUS .request primitive with Cause "invalid XID response". SM shall then deactivate all PDP contexts for 
that SAPI. 

If the originator of the establishment procedure receives an LL-RELEASE.indication with Cause "no peer response" or 
an LL-STATUS. indication with Cause "no peer response", then it shall inform the SM sub-layer using the SNSM- 
STATUS. request primitive with Cause "no peer response", wait for an implementation-specific amount of time, and re- 
invoke the establishment procedure. Before the establishment procedure is re-invoked, N-PDUs arriving at the SNDCP 
layer for delivery to the LLC layer shall be buffered, if possible. 

If the SNDCP layer receives an LL-RELEASE.indication with Cause "normal release", it shall buffer, if possible, all 
downlink N-PDUs for NSAPIs using the affected SAPI that requires acknowledged peer-to-peer LLC operation. 
Transfer of N-PDUs for NSAPIs that do not require acknowledged peer-to-peer LLC operation shall not be affected. 

If the originator of the establishment procedure detects a collision (receiving an LL-ESTABLISH.indication primitive 
after sending an LL-ESTABLISH.request or LL-XID.request primitive, or receiving an LL-XID. indication primitive 
after sending an LL-XID.request primitive), it shall treat the LL-ESTABLISH.request or LL-XID.request primitive sent 
as not transmitted, and process the LL-ESTABLISH.indication or LL-XID. indication primitive received. If the 
LL-ESTABLISH.request or LL-XID.request contains one or more XID parameters, or one or more compression fields 
in an XID parameter, or one or more parameters in a compression field, that are not negotiated as part of the collision 
resolution, then negotiation of these XID parameters shall be performed at the earliest opportunity after conclusion of 
the collision resolution. 

6.2.2 Release of acknowledged peer-to-peer LLC operation 



6.2.2.1 



Release criteria 



If acknowledged peer-to-peer LLC operation is established for the SAPI used by a PDP context that is going to be 
deactivated or mapped to another SAPI, and if there is no other NSAPIs that require acknowledged peer-to-peer LLC 
operation using the original SAPI, then the SNDCP layer shall initiate the release procedure. 

The SNDCP layer shall initiate the release, using the procedure described in subclause 6.2.2.2, upon receipt of the 
SNSM-DEACTIVATE.indication primitive. 

The SNDCP layer at the SGSN shall also initiate the release upon receipt of the SNSM-MODIFY.indication primitive if 
an existing NSAPI is specified. 



£75/ 



(GSM 04.65 version 6.5.1 Release 1 997) 23 ETSI TS 1 01 297 V6.5.1 (1 999-1 1 ) 

6.2.2.2 Release procedure 

The SNDCP layer shall initiate the release by sending a LL-RELEASE.request primitive to the relevant LLC SAP. The 
Local parameter shall be set if the release is the result of receipt of the SNSM-DEACTIVATE.indication primitive, 
otherwise it shall not be set. 

6.2.2.3 Release initiated by the LLC layer 

The LLC layer may initiate release of the acknowledged peer-to-peer LLC operation for a S API under situations 
described in GSM 04.64. The LLC layer shall inform the SNDCP layers of the release of acknowledged peer-to-peer 
LLC operation using the LL-RELEASE.indication primitive. SNDCP shall process the LL-RELEASE.indication 
primitive as described in subclause 6.2.1.4. 

6.3 N-PDU buffering 

The N-PDUs shall be buffered in the SNDCP layer before they are compressed segmented and transmitted to the LLC 
layer. The reception of an SNSM-DEACTIVATE.indication shall trigger the deletion of the buffer for the related 
NSAPI. 

For acknowledged data transfer, the SNDCP entity shall buffer an N-PDU until successful reception of all SN-PDUs 
carrying segments of the N-PDU have been confirmed. The confirmation is carried out using the LL-DATA.confirm 
primitive from the LLC layer or the SNSM-SEQUENCE.indication primitive from the SM layer. Buffered N-PDUs 
which have been completely received as indicated by the acknowledgements in an LL-D AT A. confirm primitive shall be 
discarded. During the Inter-SGSN RA Update, buffered N-PDUs whose complete reception by the MS has been 
confirmed in the SNSM-SEQUENCE.indication primitive shall be discarded, as defined in GSM 09.60 [7] and 
GSM 03.60 [3]. 

For unacknowledged data transfer, the SNDCP shall delete an N-PDU immediately after it has been delivered to the 
LLC layer. 

6.4 Management of delivery sequence 

The SNDCP layer shall retain the delivery sequence of N-PDUs of each NSAPI between the peer entities. The delivery 
sequence of N-PDUs from different NS APIs may be changed according to the QoS profiles. 

6.5 Protocol control information compression 

Protocol control information compression is an optional SNDCP feature. Only TCP/IP header compression has been 
specified in the present document. 

Negotiation of the supported algorithms and their parameters is carried out between MS and SGSN using the SNDCP 
XID parameters (see clause 8). 

6.5.1 Negotiation of multiple protocol control information compression 
types 

Each SNDCP entity that supports protocol control information compression shall be able to negotiate one or several 
protocol control information compression entities with the compression field format shown in Figure 7. The negotiation 
shall be carried out using the XID parameter negotiation specified in subclause 6.8. The initiating entity defines a set of 
requested compression entities, together with the algorithm and parameters for each compression entity. The set of 
entities and their algorithms and parameters shall be transmitted to the peer entity. The peer entity responds with the set 
of negotiated entities and their algorithms and parameters. The peer entity shall select the proposed parameter values or 
other appropriate values for the negotiated entities. 
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6.5.1.1 



Format of the protocol control information compression field 



Bit 


8 


7 


6 


5 


4 


3 


2 
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Octet 1 


P 


X 


X 


Entity number 


Octet 2 


X 


X 


X 


Algorithm type 


Octet 3 


Length=n-3 1 


Octet 4 


PC0MP1 


PC0MP2 








Octet X 


High-order octet 






Octet n 


Low-order octet 



Figure 7: Protocol control information compression field format for SNDCP XID negotiation 

6.5.1.1.1 Spare bit (X) 

The X bit shall be set to by the transmitting SNDCP entity and shall be ignored by the receiving SNDCP entity.. 



6.5.1.1.2 



Propose bit (P) 



The P bit shall be set to 1 if a new compression entity is being proposed, otherwise it shall be set to 0. If the P bit is set 
to 1, then all octets shall be included, otherwise octet 2 and octets 4 to x-1 shall not be included. If the P bit is set to 1, 
then only enough number of octets shall be included to contain the number of PCOMP values needed by the 
corresponding compression algorithm (e.g., PC0MP3 and PCOMP4 shall not be included if the number of PCOMP 
values needed by a compression algorithm is one or two). If an odd number of PCOMP values are used by a 
compression algorithm, then the last PCOMP value shall be set to in the compression field by the transmitting SNDCP 
entity, and it shall be ignored by the receiving SNDCP entity. 



6.5.1.1.3 



Entity number 



The entity number shall be used to identify a protocol control information compression entity on a SAPI. The entity 
number shall be assigned using the following rules: 

The entity number shall be an integer from to 3 1 . 

The entity number shall be assigned independently on each of the SAPIs. 

An entity number shall be in one of the three states: unassigned, selected, or assigned. 

When a new compression entity is to be proposed, an unassigned entity number shall become selected. If there is 
no unassigned entity number left, the compression entity shall not be proposed. 

A selected entity number shall become assigned if the corresponding proposed compression entity is created as a 
result of the XID negotiation, otherwise it shall become unassigned. 

An assigned entity number shall become unassigned when the corresponding compression entity is deleted as a 
result of an XID negotiation, or upon the receipt of the LL-RESET.indication primitive. 

In the case of a collision (see subclause 6.2.1.4) in which an entity number is currently selected: 

If the selected entity number is included with the P bit set to in the incoming SNDCP XID block, then it 
shall be assumed that the peer SNDCP entity agreed to the creation of the proposed entity but the response 
was lost. Therefore the selected entity number shall become assigned, any selected PCOMP and DCOMP 
values for the algorithm of the entity shall become assigned, and the compression entity shall be created, 
before the incoming SNDCP XID block is processed. After the incoming SNDCP XID block is processed, the 
compression entity shall be negotiated again if necessary, as defined in subclause 6.2.1.4. 

Otherwise (i.e., if the selected entity number is not included, or is included with the P bit set to 1 in the 
incoming SNDCP XID block), the selected entity number shall become unassigned, and any selected PCOMP 
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and DCOMP values for the algorithm of the entity shall become unassigned, before the incoming SNDCP 
XID block, if any, is processed. Following the collision resolution procedure, the originally-proposed 
compression entity shall be proposed again (i.e., the originally-proposed compression entity shall not be 
considered created even if the originally-selected entity number is proposed in the incoming SNDCP XID 
block) by sending the appropriate primitive (LL-ESTABLISH.request or LL-XID.request). The originally- 
selected entity number, PCOMP and DCOMP values shall be used for the compression entity being re- 
proposed if they are unassigned, otherwise a new entity number, PCOMP or DCOMP value shall be selected. 

In the case of a collision in which an entity number is currently assigned: 

If the peer SNDCP entity proposes a new compression entity with the same entity number, then it shall be 
assumed that the peer SNDCP entity negotiated the deletion of the entity but the response was lost, and the 
entity number is being reused. Therefore the original compression entity shall be deleted, the entity number 
shall become unassigned, PCOMP and DCOMP values shall be unassigned if necessary (see 
subclause 6.5.1.1.5), and then the proposed compression entity shall be responded to as usual. 

Otherwise (i.e., if the assigned entity number is not included, or is included with the P bit set to in the 
incoming SNDCP XID block), the usual rules regarding collision handling shall apply. 

In the case of a collision in which a PCOMP or DCOMP value is currently assigned to a compression algorithm: 

If the peer SNDCP entity proposes a new compression entity with the same PCOMP or DCOMP assigned to a 
different algorithm, then it shall be assumed that the peer SNDCP entity negotiated the deletion of all entities 
using the algorithm to which the PCOMP or DCOMP value was assigned, but the response was lost, and the 
PCOMP or DCOMP value is being reused. Therefore, all compression entities using that algorithm shall be 
deleted, all corresponding entity numbers shall become unassigned, and all PCOMP or DCOMP values 
assigned to the algorithm shall become unassigned, and then the proposed compression entity shall be 
responded to as usual. 

Otherwise (i.e., if the assigned PCOMP or DCOMP is not included, or is included and assigned to the same 
algorithm), the usual rules regarding collision handling shall apply. 

6.5.1.1.4 Algorithm type 

Table 4 show the list of protocol control information compression algorithms supported by the SNDCP layer. When new 
compression algorithms are needed for SNDCP, Table 4 shall be updated. 

Table 4: List of protocol control information compression algorithms supported by SNDCP 



Compression algorithm 


Algorithm type (Range 0-31) 


RFC1144 





- 


Other values Reserved 



6.5.1.1.5 PCOMP 

One or more PCOMP values shall be assigned dynamically to a compression algorithm, based on the negotiation of the 
XID parameters for protocol control information compression. Each of the assigned PCOMP values denotes one 
compressed frame type of that compression algorithm. 

The assignment of the PCOMP values follows the following general rules: 

- PCOMP shall be an integer from to 15. 

PCOMP value is reserved permanently for no compression. 

PCOMP shall be assigned independently on each of the S APIs. 

An assigned PCOMP value applies to all NSAPIs mapped to the same SAPI. 

PCOMP values shall be assigned to compression algorithms, not to compression entities (i.e., the same PCOMP 
value(s) shall be used by different compression entities on the same SAPI using the same compression 
algorithm). 
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A PCOMP value shall be in one of the three states: unassigned, selected, or assigned. 

When a new compression entity is to be proposed, and if PCOMP values have not yet been assigned to the 
corresponding compression algorithm, then the appropriate number of unassigned PCOMP values shall be 
selected. If there is not enough unassigned PCOMP values left, the compression entity shall not be proposed. 

A selected PCOMP value shall become assigned if the corresponding proposed compression entity is created as a 
result of the XID negotiation, otherwise it shall become unassigned. 

An assigned PCOMP value shall become unassigned when the corresponding compression algorithm is no longer 
in use by any compression entity, or upon the receipt of the LL-RESET. indication primitive. 

In the case of a collision (see subclause 6.2. 1 .4), the handling of PCOMP values shall be in accordance with 
subclause 6.5.1.1.3. 

While transferring data, the compressed frame type for an N-PDU is conveyed in the PCOMP field of the SNDCP 
header of the first SN-PDU belonging to the N-PDU. Any successfully negotiated algorithm may be used for 
compression of an N-PDU. 

6.5.1 .2 Resetting compression entities following SNDCP XID negotiation 

The LL-Establish primitives shall be used for the negotiation of protocol control information compression if: 

one or more parameters, excluding the applicable NS APIs, of existing compression entities used with 
acknowledged peer-to-peer LLC operation are changed by the originator of the negotiation; or 

one or more NS APIs are removed, by the originator of the negotiation, from existing compression entities used 
with acknowledged peer-to-peer LLC operation. 

Otherwise, either the LL-Establish primitives or the LL-XID primitives may be used. 

If the LL-XID primitives are used for XID negotiation, then in addition to restrictions specified elsewhere in the present 
document, the following parameters of the protocol control information compression entities are non-negotiable by the 
responding SNDCP entity: 

any parameter of existing compression entities used with acknowledged peer-to-peer LLC operation. 

If one or more parameters, other than the applicable NS APIs, of a compression entity used with unacknowledged peer- 
to-peer LLC operation are changed, the compression entity shall be reset locally upon completion of the SNDCP XID 
negotiation. 

6.5.1 .3 Parameters for compression entities 

On negotiating a compression entity, not all the parameters of the entity have to be specified. If a parameter is to be 
included, all the preceding parameters shall also be specified, and the length field shall be set to the sum of the lengths 
of all the parameters specified. If any of the parameters is not specified, the rules in subclause 6.8.2 shall apply. 



6.5.2 TCP/IP header compression 



The protocol control information compression method is specific for each network layer protocol type. TCP/IP (IPv4) 
header compression is specified in RFC 1 144 [9]. 
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6.5.2.1 



Parameters 



Table 5 contains the parameters defined for a compression entity using TCP/IP header compression. They may be 
negotiated during SNDCP XID negotiation. 

Table 5: RFC 1144 TCP/IP header compression parameters 









Parameters | 


Algorithm 
Name 


Algorithm 
Type 


Length 


Parameter 
Name 


Format 


Range 


Sense of 
Negotiation 


Default 
Value 


RFC 1144 





0, 2 or 3 if 
P bit is 0, 

1 , 3 or 4 if 
P bit is 1 . 


Applicable 
NSAPIs 


bbbbbbbb 
bbbOOOOO 


0, 32, 64, 
... ,65504 


down (each bit 
separately) 





So- 1 


bbbbbbbb 


through 
255 


down 


15 



6.5.2.1.1 Applicable NSAPIs 

See subclause 7.1.3. 

6.5.2.1.2 So 

The number of state slots, as defined in [9]. The So range is 1 through 256, with 16 as default value. 



6.5.2.2 



Assignment of PCOMP values 



The underlying service shall be able to distinguish the three types of compressed N-PDUs (i.e.. Type IP, Uncompressed 
TCP, and Compressed TCP), as defined in RFC 1144 [9]. These three N-PDU types are differentiated by using different 
PCOMP values. 

Two PCOMP values shall be assigned to the TCP/IP header compression algorithm. PCOMP 1 shall contain the PCOMP 
value for the frame type "Uncompressed TCP", and PCOMP2 shall contain the PCOMP value for the frame type 
"Compressed TCP". 

The PCOMP value of shall be used for the frame type "Type IP". 

6.5.2.3 Error Recovery 

When TCP/IP header compression is used with unacknowledged peer-to-peer LLC operation, the decompression entity 
shall be notified in case an N-PDU is dropped, so that error recovery procedure (see [9]) can be invoked. 



6.6 Data compression 



Data compression is an optional SNDCP feature. Data compression applies to both SN-DATA and SN-UNITDATA 
primitives. 

Data compression, if used, shall be performed on the entire N-PDU, including the possibly compressed protocol control 
information. 

Figure 8 shows an example how the SNDCP functions may be used. Several NSAPIs may use a common data 
compression entity, i.e., the same compression algorithm and the same dictionary. Separate data compression entities 
shall be used for acknowledged (SN-DATA) and unacknowledged (SN-UNITDATA) data transfer. Several NSAPIs 
may be associated with one SAPI, i.e., they may use the same QoS profile. 
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SNDCP users 



NSAPI 




PDP 

or 

Relay 



PDP 

or 

Relay 



Protocol 
compr. 



Data 
compr. 



Data 
compr. 





15 




SNDCP layer 



Protocol 
compr. 



Protocol 
compr. 



Data 
compr. 





sAPi cJl3^ cJ2) c2) cJ}!) 



LLC layer entity 



Figure 8: An example for the usage of NSAPIs, SNDCP functions, and SAPIs 

6.6.1 Negotiation of multiple data compression types 

Each SNDCP entity that supports data compression shall be able to negotiate one or several data compression entities 
with the compression field format shown in Figure 9. The negotiation shall be carried out using the XID parameter 
negotiation specified in subclause 6.8. The initiating entity defines a set of requested compression entities, together with 
the algorithm and parameters for each compression entity. The set of entities and their algorithms and parameters shall 
be transmitted to the peer entity. The peer entity responds with the set of negotiated entities and their algorithms and 
parameters. The peer entity shall select the proposed parameter values or other appropriate values for the negotiated 
entities. 

For each NSAPI one or more data compression are chosen. This choice is also indicated in the SNDCP XID. Only 
NSAPIs that are using the same SAPI may use the same data compression entity. If more than one compression entity is 
chosen for an NSAPI, these entities must use different data compression algorithms. However, only one data 
compression entity is used for one N-PDU; i.e., the used data compression entity may be changed from N-PDU to 
N-PDU. 
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6.6.1.1 



Format of the data compression field 



Bit 


8 


7 


6 


5 


4 


3 


2 


^ 


Octet 1 


P 


X 


X 


Entity number 


Octet 2 


X 


X 


X 


Algorithm type 


Octet 3 


Length=n-3 1 


Octet 4 


DC0MP1 


DC0MP2 








Octet X 


High-order octet 






Octet n 


Low-order octet 



Figure 9: Data compression field format for SNDCP XID negotiation 

6.6.1.1.1 Spare bit (X) 

The X bit shall be set to by the transmitting SNDCP entity and shall be ignored by the receiving SNDCP entity. 



6.6.1.1.2 



Propose bit (P) 



The P bit shall be set to 1 if a new compression entity is being proposed, otherwise it shall be set to 0. If the P bit is set 
to 1, then all octets shall be included, otherwise octet 2 and octets 4 to x-1 shall not be included. If the P bit is set to 1, 
then only enough number of octets shall be included to contain the number of DCOMP values needed by the 
corresponding compression algorithm (e.g., DCOMP3 and DCOMP4 shall not be included if the number of DCOMP 
values needed by a compression algorithm is one or two). If an odd number of DCOMP values are used by a 
compression algorithm, then the last DCOMP value shall be set to in the compression field by the transmitting SNDCP 
entity, and it shall be ignored by the receiving SNDCP entity. 



6.6.1.1.3 



Entity number 



The entity number shall be used to identify a data compression entity on a SAPI. See subclause 6.5.1.1.3 for the rules for 
assigning entity numbers. The assignment of entity numbers for protocol control information compression entities and 
data compression entities shall be independent. 



6.6.1.1.4 



Algorithm type 



Table 6 shows the list of data compression algorithms supported by the SNDCP layer. When new compression 
algorithms are needed for SNDCP, Table 6 shall be updated. 

Table 6: List of data compression algorithms supported by SNDCP 



Data compression 
algorithm 


Algorithm type 
(Range 0-31) 


V.42 bis 





- 


Other values Reserved 



6.6.1.1.5 



DCOMP 



One or more DCOMP values shall be assigned dynamically to a compression algorithm, based on the negotiation of the 
XID parameters for data compression. Each of the assigned DCOMP values denotes one compressed frame type of that 
compression algorithm. 
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The assignment of the DCOMP values shall follow the rules for the assignment of PCOMP values in 
subclause 6.5.1.1.5. 

While transferring data, the compressed frame type for an N-PDU is conveyed in the DCOMP field of the SNDCP 
header of the first SN-PDU belonging to the N-PDU. Any successfully negotiated algorithm may be used for 
compression of an N-PDU. 

6.6.1 .2 Resetting compression entities following SNDCP XID negotiation 

The LL-Establish primitives shall be used for the negotiation of data compression if: 

one or more parameters, excluding the applicable NS APIs, of existing compression entities used with 
acknowledged peer-to-peer LLC operation are changed by the originator of the negotiation; or 

one or more NS APIs are removed, by the originator of the negotiation, from existing compression entities used 
with acknowledged peer-to-peer LLC operation. 

Otherwise, either the LL-Establish primitives or the LL-XID primitives may be used. 

If the LL-XID primitives are used for XID negotiation, then in addition to restrictions specified elsewhere in the present 
document, the following parameters of the data compression entities are non-negotiable by the responding SNDCP 
entity: 

any parameter of existing compression entities used with acknowledged peer-to-peer LLC operation. 

If one or more parameters, other than the applicable NS APIs, of a compression entity used with unacknowledged peer- 
to-peer LLC operation are changed, the compression entity shall be reset locally upon completion of the SNDCP XID 
negotiation. 



6.6.1.3 



Parameters for compression entities 



On negotiating a compression entity, not all the parameters of the entity have to be specified. If a parameter is to be 
included, all the preceding parameters shall also be specified, and the length field shall be set to the sum of the lengths 
of all the parameters specified. If any of the parameters is not specified, the rules in subclause 6.8.2 shall apply. 

6.6.2 Management of V.42 bis data compression 

ITU-T V.42 bis [8] data compression may be used with SN-DATA primitives and SN-UNITDATA primitives. 

6.6.2.1 Parameters 

Table 7 contains the parameters defined for a compression entity using V.42 bis data compression. They may be 
negotiated during SNDCP XID negotiation. 

Table 7: V.42 bis data compression parameters 









Parameters | 


Algorithm 
Name 


Algorithm 
Type 


Length 


Parameter 
Name 


Format 


Range 


Sense of 
Negotiation 


Default 
Value 


V.42 bis 





0, 2, 3, 5, 
or 6 if 
P bit is 0, 
1,3,4,6, 
or 7 if 
P bit is 1 . 


Applicable 
NSAPIs 


bbbbbbbb 
bbbOOOOO 


0, 32, 64, 
... ,65504 


down (each bit 
separately) 





Po 


OOOOOObb 


through 
3 


down (each 

direction 

separately) 


3 


Pi 


bbbbbbbb 
bbbbbbbb 


512 

through 

65535 


down 


2048 


P2 


bbbbbbbb 


6 through 
250 


down 


20 
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6.6.2.1.1 Applicable NSAPIs 

See subclause 7.1.3. 

6.6.2.1.2 Po 

Two bits are used to indicate the usage of compression, one bit for each direction. 

00 compress neither direction 

01 compress MS-to-SGSN direction only 

10 compress SGSN-to-MS direction only 

1 1 compress both directions 

6.6.2.1.3 Pi 

Maximum number of codewords in the compressor dictionary (see [8]). 

6.6.2.1.4 P2 

Maximum number of characters in an uncompressed data string that is accepted to be encoded. 

6.6.2.2 Assignment of DCOMP values 

One DCOMP value shall be assigned (as DCOMPl) to the V.42 bis data compression algorithm. 

6.6.2.3 Operation of V.42 bis data compression 

When V.42 bis is used with SN-DATA primitives, the data in the compression entity shall be flushed (using the 
C-FLUSH primitive defined in [8]) and added to the compressed N-PDU before the compressed N-PDU is sent. 

When V.42 bis is used with SN-UNITDATA primitives, the compression entity shall be reset (using the C-INIT 
primitive defined in [8]) before an N-PDU is compressed or decompressed. After compression, the data in the 
compression entity shall be flushed (using the C-FLUSH primitive defined in [8]) and added to the compressed N-PDU 
before the compressed N-PDU is sent. The LLC protocol shall operate in the protected mode of operation. 

When V.42 bis is used with SN-DATA primitives and an error is detected by the decoder, the SNDCP entity shall use 
LL-ESTABLISH.request primitive to reset the acknowledged peer-to-peer LLC operation for the SAPI used. 



6.7 Segmentation and reassembly 



Segmentation shall be performed by the SNDCP entity to ensure that any SN-PDU transmitted is no longer than N201 
(see GSM 04.64 [6]). The receiving SNDCP entity shall reassemble the segments back to the original (possibly 
compressed) N-PDU. 

The segmentation and reassembly procedures are different for acknowledged and unacknowledged mode of operation. 

6.7.1 General 
6.7.1.1 Segmentation 

A (possibly compressed) N-PDU shall be segmented into one or more SN-PDUs. The length of each SN-PDU shall not 
be greater than N201-I (for acknowledged mode) or N201-U (for unacknowledged mode). 

The F bit in the SNDCP header shall be set to 1 for the first segment, and for all subsequent segments. 

For unacknowledged peer-to-peer LLC operation, DCOMP and PCOMP shall be included in the header when the F bit 
is set to 1, and shall not be included when the F bit is set to 0. 
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For acknowledged peer-to-peer LLC operation, DCOMP, PCOMP and N-PDU number shall be included in the header 
when the F bit is set to 1, and shall not be included when the F bit is set to 0. 

If an SN-PDU is received with the F bit set to 1 when a non-first segment is expected, and if DCOMP, PCOMP and (in 
the acknowledged mode) the N-PDU number all remain unchanged comparing to the first segment, then the SN-PDU 
shall be processed as normal. 

The M bit in the SNDCP header shall be set to for the last segment, and 1 for all previous segments. 

If only one SN-PDU is generated for an N-PDU, the F bit shall be set to 1 and the M bit set to 0. 

6.7.1.2 Reassembly 

During reassembly, DCOMP and PCOMP for an N-PDU shall be retrieved from the first segment (F bit set to 1). For 
acknowledged peer-to-peer LLC operation, the N-PDU number shall also be retrieved from the first segment. 

The receiving SNDCP entity shall be in one of the following three receiving states: 

the Receive First Segment state, in which the SNDCP entity shall expect the F bit set to 1 in the next received 
SN-PDU; 

the Receive Subsequent Segment state, in which the SNDCP entity shall expect the F bit set to in the next 
received SN-PDU; or 

the Discard state, in which the SNDCP entity shall discard any SN-PDU received. 

The Receive First Segment state shall be entered: 

- upon receipt of an SNSM-ACTIVATE.indication; 

upon receipt of an SNSM-MODIFY. indication which indicates a change in SAPI or a change in peer-to-peer 
LLC operation mode; 

upon receipt of an LL-ESTABLISH. indication or an LL-ESTABLISH. confirm; or 

when the M bit is set to in the received SN-PDU, except for situations specified in subclause 6.7.4. 

The Receive Subsequent Segment state shall be entered: 

when the M bit is set to 1 in the received SN-PDU, except for situations specified in subclause 6.7.4. 

6.7.2 Segmentation and reassembly in acknowledged mode 

Segmentation and reassembly in acknowledged mode shall follow the general procedures stated in subclause 6.7. L 

6.7.3 Segmentation and reassembly in unacknowledged mode 

In addition to the general procedure in subclause 6.7.1, a segment number shall be used due to the unreliable nature of 
the unacknowledged mode. 

The Segment number is a sequence number assigned to each SN-UNITDATA PDU. The sequence number shall be set 
to in the first SN-UNITDATA PDU of an N-PDU, and incremented by 1 for each subsequent SN-UNITDATA PDU. 
Modulo 16 operation is applied. 

The received segments belonging to the same N-PDU shall be re-ordered, if possible. If a timer (implementation 
dependent) elapses before all segments are received, the segments shall be discarded. Reassembly operation described in 
subclauses 6.7.1 and 6.7.4 shall be performed after re-ordering. 
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6.7.4 Exception situations 

6.7.4.1 Receive First Segment state 

If an SN-UNITDATA PDU is received with the F bit set to 0, the SN-UNITDATA PDU shall be discarded. The 
Receive First Segment state shall be entered if the M bit is set to 0, otherwise the Discard state shall be entered. 

If an SN-DATA PDU is received with the F bit set to 0, the SN-DATA PDU shall be discarded, and the acknowledged 
LLC operation shall be re-established for the SAPI used. 

6.7.4.2 Receive Subsequent Segment state 

If an SN-UNITDATA PDU is received with the F bit set to 1, and if DCOMP or PCOMP is different from those in the 
first segment, then the SN-UNITDATA PDU and all previous segments belonging to the same N-PDU shall be 
discarded. The Received First Segment state shall be entered if the M bit is set to 0, otherwise the Discard state shall be 
entered. 

If an SN-DATA PDU is received with the F bit set to 1, and if DCOMP, PCOMP or N-PDU number is different from 
those in the first segment, then the SN-DATA PDU and all previous segments belonging to the same N-PDU shall be 
discarded, and the acknowledged LLC operation shall be re-established for the SAPI used. 

6.7.4.3 Discard state 

If an SN-PDU is received with the M bit set to 1, the SN-PDU shall be discarded and the SNDCP entity shall remain in 
the Discard state. 

If an SN-PDU is received with the M bit set to 0, the SN-PDU shall be discarded and the Receive First Segment state 
entered. 



6.8 XID parameter negotiation 



Negotiation of XID parameters between peer SNDCP entities may be carried out to ensure optimal information transfer. 
The parameters are called SNDCP exchange identity (XID) parameters. 

SNDCP XID parameter negotiation may be initiated by the SNDCP entity at the MS or at the SGSN. If SNDCP XID 
parameters are to be changed, SNDCP XID negotiation shall be initiated prior to data transfer - the MS shall initiate 
SNDCP XID negotiation upon receipt of SNSM-ACTIVATE.indication; the SGSN shall initiate SNDCP XID 
negotiation upon receipt of the SNSM-MODIFY.indication primitive if an NS API has been put into use (in the case of 
an Inter-SGSN Routeing Area Update), or if the change in QoS profile to an existing NS API results in a change in 
compressor(s) used by the NSAPI. 

When an NSAPI no longer uses a compression entity due to a PDP context deactivation or a PDP context modification, 
an SNDCP XID negotiation shall be performed to remove the NSAPI from the Applicable NS APIs of the compression 
entity. The negotiation shall be initiated by the MS upon receipt of the SNSM-DEACTIV ATE. indication in the case of 
PDP context deactivation, or by the SGSN upon receipt of the SNSM-MODIFY.indication in the case of PDP context 
modification. 

The XID negotiation is a one-step procedure; i.e., the initiating end proposes parameter values, and the responding end 
either accepts these or offers different values in their place according to the XID negotiation rules described in the 
present document; the rules limit the range of parameter values as well as the sense of negotiation. The initiating end 
accepts (or rejects) the values in the response; this concludes the negotiation. 

The block format for the SNDCP XID parameter negotiation is shown in Figure 10. Not all parameters have to be 
included in the XID block, only parameters that are negotiated. Parameters may be included in any order. Also it shall 
be possible to negotiate parameters for more than one NSAPI in one XID block since more than one NSAPI can use the 
same SAPI. 
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Bit 


8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 


Parameter type=0 


Octet 2 


Length=1 


Octet 3 


Version number 


Octet 4 


Parameter type=1 


Octet 5 


Length=n-5 


Octet 6 


P 


X 


X 


Entity number 


Octet 7 (optional) 




Octet 8 


Length=k-8 


Octet 9 ... (optional) 




Octet j 


High-order octet 






Octet k 


Low-order octet 


Octet k+1 


P 


X 


X 


Entity number 


Octet k+2 (optional) 




Octet k+3 


Length=m-(k+3) 


Octet k+4... (optional) 




Octet k+y 


High-order octet 






Octet m 


Low-order octet 






Octet n 


Low-order octet 


Octet n+1 


Parameter type=2 


Octet n+2 


Length=r-(n-H2) 
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Figure 10: Example of SNDCP XID block format 

The SNDCP user uses SN-XID .request to initiate the negotiation of the XID parameters. The SNDCP entity sends the 
proposed SNDCP XID parameters to the LLC SAP with the LL-XID.request or LL-ESTABLISH.request. The LLC 
SAP shall issue an XID command containing the SNDCP XID parameters (see GSM 04.64). The peer LLC SAP shall, 
upon receipt of the XID command, indicate the SNDCP XID parameters to SNDCP entity using LL-XID. indication or 
LL-ESTABLISH. indication. The peer SNDCP entity shall select appropriate values for the proposed parameters or 
negotiate the appropriate values with the SNDCP user entity with the SN-XID. indication and SN-XID. response 
primitives. When the appropriate parameter values are known by the peer SNDCP entity, it shall use the 
LL-XID. response or LL-ESTABLISH.response primitive to continue negotiation. Upon reception of the response, the 
LLC SAP shall send the received parameters to the SNDCP entity using the LL-XID. confirm or 
LL-ESTABLISH.confirm primitive. The SNDCP entity delivers the negotiated parameters to the SNDCP user. This is 
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illustrated in Figure 1 1 . The originator of the negotiation shall apply the new parameter values after it has received the 
'confirm' primitive. The responding end of the negotiation shall apply the new parameter values after it has sent the 
replying 'response' primitive. 

Following the sending of the LL-XID .request primitive, the SNDCP layer shall suspend the transfer of SN-DATA and 
SN-UNITDATA primitives to the LLC SAP to which the LL-XID .request is sent. Transfer of SN-DATA and 
SN-UNITDATA primitives shall resume when the SNDCP XID negotiation ends through one of the following means: 

successful (receiving LL-XID. confirm); 

failure (receiving LL-RELEASE.indication, or LL-STATUS.indication); or 

successful following collision resolution (receiving LL-ESTABLISH.indication and sending 
LL-ESTABLISH.response, or receiving LL-XID. indication and sending LL-XID.response, see 
subclause 6.2. L4). 

LLC may also initiate LLC XID negotiation, in which case LLC may send an LL-XID. indication to inform SNDCP the 
values of N201-I and N201-U. This is illustrated in Figure 12. If the SNDCP entity receives an LL-XID. indication 
without an SNDCP XID block, it shall not respond with the LL-XID.response primitive. 

Negotiation of SNDCP version number is always between the peer SNDCP entities. The version number is not known 
by the SNDCP user. However, negotiation of the parameters for compression algorithms may be carried out between the 
SNDCP user entities. 

Negotiation of SNDCP XID parameters for an NSAPI shall be carried out in the SAPI to which the NSAPI is mapped. 
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Figure 11: SNDCP XID negotiation procedure 
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Figure 12: LLC XID negotiation procedure 
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6.8.1 Negotiation of compression entities 

For parameter type 1 and 2, multiple compression fields (as shown in Figure 7 and Figure 9) may be specified. Each 
compression field corresponds to a compression entity. 

In each compression field, the "Applicable NSAPIs" parameter indicates the NSAPIs that uses the compression entity. 
The parameter, if included, shall consist of 2 octets. Multiple NSAPIs may share the same compression entity by setting 
multiple bits in the parameter. NSAPIs requiring acknowledged peer-to-peer LLC operation and unacknowledged peer- 
to-peer LLC operation shall not share the same compressor (see subclause 6.10). 

During SNDCP XID negotiation or re-negotiation, if a parameter type is specified in the SNDCP XID block, 
compression entities currently in use and compression entities proposed to be added may be included in the SNDCP 
XID block. Not all entities need to be included in the SNDCP XID block. If a compression entity is not included, the 
value of its parameters shall be determined by the rules defined in subclause 6.8.2. 

If, implicitly or explicitly (see subclause 6.8.2), a compression entity is specified in the responding SNDCP XID block 
with one or more bits set to 1 in the "Applicable NSAPIs" parameter, the compression entity shall be created (if it does 
not exist yet). 

If, implicitly or explicitly, a compression entity is specified in the responding SNDCP XID block with no bit set to 1 in 
the "Applicable NSAPIs" parameter, the compression entity shall be deleted (if it currently exists). 

If, implicitly or explicitly, one or more bits are set to 1 in the "Applicable NSAPIs" parameter of a compression entity in 
the responding SNDCP XID block, the NSAPIs corresponding to these bits shall start using (or continue to use) the 
compression entity. 

If, implicitly or explicitly, one or more bits are set to in the "Applicable NSAPIs" parameter of a compression entity in 
the responding SNDCP XID block, the NSAPIs corresponding to these bits shall release the compression entity (if they 
have been using the compression entity). 



6.8.2 Values of SNDCP XID parameters 



In this subclause, the term "parameter" refers to an SNDCP XID parameter, a compression field (for parameter type I or 
type 2), or a parameter for a compression field. 

If an SNDCP XID parameter has not been negotiated, default values shall apply. The default value for a compression 
field (entity) is "non-existing". 

If the originating SNDCP XID block does not include a parameter (implicit command), it shall be treated as equivalent 
to requesting for the current value for the parameter. The responder may explicitly include this parameter in its response. 
If the responder explicitly includes the parameter in the response, then it shall also explicitly include this parameter the 
next time it initiates an SNDCP XID negotiation, and it shall select the proper primitive (LL-ESTABLISH. request or 
LL-XID .request) based on the rules in subclauses 6.5.1.2 and 6.6.1.2. 

If a parameter is included in the originating SNDCP XID block and the responder does not include the parameter in its 
response (implicit response), it shall be treated as equivalent to responding with the value proposed by the originator. 

If both the originator and the responder do not include a parameter in the negotiation, the value of the parameter is not 
changed. 



6.8.3 Exception handling 



In this subclause, the term "parameter" may refer, wherever applicable, to an SNDCP XID parameter, a compression 
field (for parameter type 1 or 2), or a parameter for a compression field. 

If the originating SNDCP XID block includes a parameter with unrecognised Type field, the parameter shall be ignored 
by the responder. 

If the originating SNDCP XID block includes a parameter with unsupported length or an out-of -range value, then the 
responder shall respond to the parameter with lengths and values set according to the responder's preference. 
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If the originating SNDCP XID block includes parameter type 1 or 2 which violates the rules in subclause 6.8.1, the 
responder shall treat the parameter as not transmitted by the originator, and responds according to subclause 6.8.2. 

If the originating SNDCP XID block includes a parameter with duplicated instances, the subsequent instances of the 
duplicated parameter shall be ignored. 

If the originating SNDCP XID block is sent on LL-XID primitives and contains prohibited changes (see 
subclauses 6.5.1.2 and 6.6.1.2) to the parameters of compression entities used with acknowledged peer-to-peer LLC 
operation, then the responder shall respond with these parameters set to their previously-negotiated values. 

In the originating SNDCP XID block, excluding the collision scenarios described in subclause 6.5.1.1.3, when an 
assigned entity number is included with the P bit set to 1, the algorithm and the PCOMP and DCOMP fields shall be 
ignored if they are the same as the previously-assigned values. If the algorithm and PCOMP or DCOMP fields are not 
the same as the previously-assigned values, then the Applicable NS APIs field of the compression field in question shall 
be set to in the response, and an SNSM-STATUS. request primitive with Cause "invalid XID command" shall be sent 
to the SM sub-layer. SM shall then deactivate all PDP contexts for this SAPI. 

In the originating SNDCP XID block, if an unassigned entity number is included with the P bit set to 0, then the 
Applicable NSAPIs field in the response shall be set to 0. 

In the originating SNDCP XID block, excluding the collision scenarios described in subclause 6.5.1.1.3, if one or more 
of the PCOMP or DCOMP specified is already assigned to a different compression algorithm, then the Applicable 
NSAPIs field of the compression field in question shall be set to in the response, and an SNSM-STATUS .request 
primitive with Cause "invalid XID command" shall be sent to the SM sub-layer. SM shall then deactivate all PDP 
contexts for this SAPI. 

In the originating SNDCP XID block, if one or more new PCOMP or DCOMP values are specified for an existing 
compression algorithm, then the Applicable NSAPIs field of the compression field in question shall be set to in the 
response, and an SNSM-STATUS .request primitive with Cause "invalid XID command" shall be sent to the SM sub- 
layer. SM shall then deactivate all PDP contexts for this SAPI. 

If the responding SNDCP XID block includes a parameter with unrecognised Type field, unsupported length, an 
out-of-range value or a value violating the sense of negotiation, a parameter type 1 or 2 which violates the rules in 
subclause 6.8.1, a parameter with duplicated instances, contains prohibited changes (see subclauses 6.5.1.2 and 6.6.1.2) 
to the parameters of compression entities used with acknowledged peer-to-peer LLC operation when the SNDCP XID 
block is sent on LL-XID primitives, or a compression field with the P bit set to 1, then the originator shall ignore the 
block and reinitiate the negotiation. If the renegotiation fails for an implementation-specific number of times, the 
originating SNDCP layer shall send an SNSM-STATUS. request primitive with Cause "invalid XID response" to the SM 
sub-layer. SM shall then deactivate all PDP contexts for this SAPI. 

6.9 Data transfer 
6.9.1 Acknowledged mode 

The SNDCP entity shall initiate acknowledged data transmission only if the PDP context for the NS API identified in the 
SN-DATA.request has been activated and if acknowledged LLC operation has been established. 

The N-PDU number in acknowledged mode is a number assigned to each N-PDU received by SNDCP through an 
SN-DATA.request. N-PDU numbers for different NSAPIs shall be assigned independently. The N-PDU number shall be 
included in the SNDCP header of the first segment of an N-PDU. 

Two variables, the Send N-PDU number and the Receive N-PDU number, shall be maintained for each NSAPI using 
acknowledged peer-to-peer LLC operation. When an NSAPI using acknowledged peer-to-peer LLC operation is 
activated, the Send N-PDU number and the Receive N-PDU number shall be set to 0. The Send N-PDU number and 
Receive N-PDU number shall also be set as described in subclause 5.1.2.22. Modulo 256 operation shall be applied to 
the Send N-PDU number and the Receive N-PDU number. 

Upon reception of an SN-DATA.request, the SNDCP entity shall assign to the N-PDU received the current value of the 
Send N-PDU number as the N-PDU number, increment the Send N-PDU number by 1, perform the compression and 
segmentation functions, then forward the SN-PDU(s) in LL-DATA.request to the LLC layer. If an N-PDU number is 
already present in the SN-DATA.request, then no new N-PDU number shall be assigned to the N-PDU, and the Send 
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N-PDU number shall not be incremented. The N-PDU shall be stored into a buffer in the SNDCP entity. The buffered 
N-PDU shall be deleted when the SN-DATA PDU carrying the last segment of the N-PDU is confirmed by an 
LL-D ATA. confirm primitive, or when the entire N-PDU is confirmed by an SNSM-SEQUENCE. indication primitive. 

During normal operation (i.e., not in the recovery state), when the peer SNDCP entity receives the SN-PDU(s) in an 
LL-DATA.indication primitive, the SNDCP entity shall reassemble and decompress the SN-PDU(s) to obtain the 
N-PDU, increment the Receive N-PDU number by 1, and forward the N-PDU to the SNDCP user with the 
SN-DATA.indication. The correct SNDCP user is identified by the NSAPI field in the SN-PDU(s). 

In the recovery state, after reassembling and decompressing the SN-PDU(s): 

if the N-PDU number of the received N-PDU is equal to the Receive N-PDU number, then the Receive N-PDU 
number shall be incremented by 1, the recovery state shall be exited and normal operation shall resume for the 
received N-PDU and all subsequently-received N-PDUs; and 

otherwise, the N-PDU shall be discarded. 

After the SNDCP entity in the SGSN receives an SNSM-STOP-ASSIGN.indication primitive for an NSAPI using 
acknowledged peer-to-peer LLC operation, it shall stop assigning N-PDU number to N-PDUs received through the 
SN-DATA.request primitive. 

If an SN-DATA PDU (T bit set to 0) is received by an NSAPI that does not use acknowledged mode, the PDU shall be 
ignored without error notification. 
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Figure 13: SNDCP acknowledged data transfer 



6.9.2 Unacknowledged mode 



The SNDCP entity shall initiate unacknowledged data transmission only if the PDP context for the NSAPI identified in 
the SN-DATA.request has been activated. The SNDCP entity may initiate unacknowledged data transmission even if the 
acknowledged peer-to-peer operation is not established for that NSAPI. 

The N-PDU number in unacknowledged mode is a number assigned to each N-PDU received by SNDCP through an 
SN-UNITDATA.request. N-PDU numbers for different NSAPIs shall be assigned independently. The N-PDU number 
shall be included in the SNDCP header of every SN-UNITDATA PDU. 

A variable, the Send N-PDU number (unacknowledged), shall be maintained for each NSAPI using unacknowledged 
peer-to-peer LLC operation. When an NSAPI using unacknowledged peer-to-peer LLC operation is activated, the Send 
N-PDU number (unacknowledged) shall be set to 0. The Send N-PDU number (unacknowledged) shall also be set as 
described in subclauses 5.1.2.1 and 5.1.2.22. Modulo 4096 operation shall be applied to the Send N-PDU number 
(unacknowledged) . 

Upon reception of an SN-UNITDATA.request, the SNDCP entity shall assign the current value of the Send N-PDU 
number (unacknowledged) as the N-PDU number of the N-PDU received, increment Send N-PDU number 
(unacknowledged) by 1, compress and segment the information, then forward the SN-PDU(s) in 

LL-UNITDATA.request to the LLC layer. The N-PDU shall be deleted immediately after the data has been delivered to 
the LLC layer. 
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When the peer SNDCP entity receives the SN-PDU(s) in the LL-UNITDATA.indication primitive, the SNDCP entity 
shall reassemble and decompress the SN-PDU(s) to obtain the N-PDU, then forwards it to the SNDCP user with the 
SN-UNITDATA.indication. The correct SNDCP user is identified by the NSAPI field in the SN-PDU(s). 

If an SN-UNITDATA PDU (T bit set to 1) is received by an NSAPI that does not use unacknowledged mode, the PDU 
shall be ignored without error notification. 

The SNDCP entity shall detect lost SN-PDUs. The SNDCP entity shall discard duphcate SN-PDUs and re-order out-of- 
sequence SN-PDUs, if possible. 
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Figure 14: SNDCP unacknowledged data transfer 

6.1 Possible combinations of SNDCP protocol functions and 
their connection to service access points 

The following combinations of SNDCP protocol functions are allowed: 
One or several NSAPIs may use one SAPI. 

- Only one SAPI shall be used by one NSAPI. 

One or several NSAPIs may use the same protocol control information compression entity. 
One NSAPI may use zero, one, or several protocol control information compression entities. 
One or several NSAPIs may use the same data compression entity. 
One NSAPI may use zero, one, or several data compression entities. 

- Separate data compression entities shall be used for SN-DATA and SN-UNITDATA PDUs. 

Separate protocol control information compression entities shall be used for SN-DATA and SN-UNITDATA 
PDUs. 

One data compression entity shall be connected to one SAPI. 

One protocol control information compression entity shall be connected to one SAPI. 

One or several protocol control information compression entities may be connected to the same data compression 
entity. 

One protocol control information compression entity shall be connected to zero, one, or several data compression 
entities. 
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Definition of SN-PDU 



7.1 



Format convention 



7.1.1 



Numbering convention 



The convention used in the present document is illustrated in Figure 15. The bits are grouped into octets. The bits of an 
octet are shown horizontally and are numbered from 1 to 8. Multiple octets are shown vertically and are numbered from 
1 toN. 



Bit 


8 


7 


6 


5 


4 


3 


2 


1 


Oct 1 




2 








N-1 


N 
















1 



Figure 15: Format convention 

7.1.2 Order of transmission 

SN-PDUs are transferred between the SNDCP layer and LLC layer in units of octets, in ascending numerical octet order 
(i.e., octet 1, 2, ..., N-1, N). The order of bit transmission is specific to the underlying protocols used across the Um 
interface and the Gb interface. 

7.1 .3 Fielcj mapping convention 

When a field is contained within a single octet, the lowest bit number of the field represents the lowest order value. 
When a field spans more than one octet, the order of bit values within each octet progressively decreases as the octet 
number increases. In that part of the field contained in a given octet the lowest bit number represents the lowest order 
value. 

For example, a bit number can be identified as a couple (o, b) where o is the octet number and b is the relative bit 
number within the octet. Figure 16 illustrates a field that spans from bit (1, 3) to bit (2, 7). The high order bit of the field 
is mapped on bit (1, 3) and the low order bit is mapped on bit (2, 7). 
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Figure 16: Field mapping convention 

Figure 17 illustrates an NSAPI field that spans from bit (1,8) to bit (2,1). NSAPI 15 is mapped to bit (1,8) and the other 
NSAPIs are mapped in decreasingly order until NSAPI that is mapped to bit (2,1). A bit set to means that the 
compression entity is not applicable to the corresponding NSAPI. A bit set to 1 means that the compression entity is 
applicable to the corresponding NSAPI. 
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Figure 17: NSAPI mapping convention 
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7.2 



SN-PDU Formats 



Each SN-PDU shall contain an integral number of octets, and shall comprise a header part and a data part. An SN-PDU 
shall contain data from a single N-PDU only. Two different SN-PDU formats are defined. The SN-DATA PDU shall be 
used for acknowledged data transfer and SN-UNITDATA PDU for unacknowledged data transfer. 
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Figure 18: SN-DATA PDU format 
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Figure 19: SN-UNITDATA PDU format 

More bit (M): 

Last segment of N-PDU. 

1 Not the last segment of N-PDU, more segments to follow. 
SN-PDU Type (T): 

SN-DATA PDU. 

1 SN-UNITDATA PDU. 
First segment indicator bit (F): 

This SN-PDU is not the first segment of an N-PDU. 

The octet including DCOMP and PCOMP is not included in the SN-DATA PDU or SN-UNITDATA PDU 
format. Also the octet for N-PDU number for acknowledged mode is not included in the SN-DATA PDU format. 

1 This SN-PDU is the first segment of an N-PDU. The octet for DCOMP and PCOMP is included in the 
SN-DATA PDU or SN-UNITDATA PDU format. Also the octet for N-PDU number for acknowledged mode is 
included in the SN-DATA PDU format. 

Spare bit (X): 

Shall be set to by the transmitting SNDCP entity and ignored by the receiving SNDCP entity. 
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NSAPI: 

Escape mechanism for future extensions. 

1 Point-to-Multipoint Multicast (PTM-M) information. 
2-4 Reserved for future use. 

5-15 Dynamically allocated NSAPI value (see subclause 6.1). 
SN-PDU with an unallocated NSAPI value shall be ignored by the receiving SNDCP entity without error notification. 
Data compression coding (DCOMP): 

No compression. 

1-14 Points to the data compression identifier negotiated dynamically (see subclause 6.6). 

15 Reserved for future extensions. 
SN-PDU with an unallocated DCOMP value shall be ignored by the receiving SNDCP entity without error notification. 
Protocol control information compression coding (PCOMP): 

No compression. 

1-14 Points to the protocol control information compression identifier negotiated dynamically (see subclause 6.5). 

15 Reserved for future extensions. 
SN-PDU with an unallocated PCOMP value shall be ignored by the receiving SNDCP entity without error notification. 
Segment number: 

0-15 Sequence number for segments carrying an N-PDU. 

N-PDU number - acknowledged mode: 

0-255 N-PDU number of the N-PDU. 
N-PDU number - unacknowledged mode: 

0-4095 N-PDU number of the N-PDU. 

8 SNDCP XID parameters 

The SNDCP XID parameters are shown in Table 8: 

Table 8: SNDCP XID parameters 



Parameter name 


Parameter 
Type 


Length 


Format 


Range 


Default value 


Units 


Sense of 
negotiation 


Version number 





1 


OOOObbbb 


0-15 





- 


down 


Data Compression 


1 


variable 


See subclause 6.6.1 


Protocol Control 

Information 

Compression 


2 


variable 


See subclause 6.5.1 



NOTE: The current version of SNDCP is 0. This is also the default value for the version number. It is assumed 
that the future versions are backward compatible with former ones. 
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